上一篇談到 System Call：當 User Program 需要 Kernel 提供服務時，可以透過受控制的方式切換 Kernel Mode。今天要看的問題就是：
當 CPU 正在執行程式時，到底是什麼機制讓它停下目前的工作，轉去處理另一件事情？
例如：

• 鍵盤突然被按下
• I/O 裝置完成工作
• Timer 到期
• 程式執行除以 0
• 程式存取了不允許的記憶體

1. Interrupt：硬體突然有事情找 CPU

假設 CPU 正在執行 Process A：

這時候某個硬體裝置發出了通知。
例如網路卡收到資料，或計時器產生了一個事件。
CPU 就可能需要暫時處理這個事件：
Process A
│
▼
▼
│
│
Interrupt!
│
├──────────────► Interrupt Handler
│ │
│ ▼
│ 處理事件
│ ◄─────────────────┘
│
│
▼
繼續執行

這種由外部硬體事件產生的通知，就是我們常說的 Interrupt。

2. 為什麼需要 Interrupt？

如果沒有 Interrupt，CPU 要知道某個裝置有沒有事情，就可能需要一直去問：

好了嗎？：)
：還沒。

好了嗎？：
：還沒。

好了嗎？：(
：還沒。

好了嗎？><(
：好了。

但 CPU 如果一直花時間檢查，就會浪費不少執行時間(Busy Waiting)。
所以 Interrupt 的作用就是：CPU 可以先執行其他工作，等裝置真的需要處理時，再透過 Interrupt 通知 CPU，這也是 Interrupt 很重要的原因之一。但如果某個裝置極度頻繁地產生 Interrupt，CPU 也可能花很多時間處理中斷。
正在執行 Process A
│
▼
Interrupt
│
▼
保存必要的執行狀態
│
▼
Interrupt Handler
│
▼
處理硬體事件
│
▼
恢復執行狀態
│
▼
繼續原本的工作

3. Exception：是程式自己出事了

Interrupt 通常來自目前指令之外的事件。
但如果今天是 CPU 執行某一條指令時，發現：

int a = 10;
int b = 0;

int c = a / b;

「等等，除數怎麼是 0？」

所以它是目前正在執行的指令所引起的意外事件，通常會被歸類為 Exception（例外）。例如：

• Divide by zero
• Invalid instruction
• Page Fault
• Protection violation

也就是說，它和目前正在執行的指令有直接關係。

4. 等等，Page Fault 也是 Exception？

Page Fault 的意思是 CPU 在進行記憶體存取時，發現目前的 Page Table 狀態無法直接完成這次存取，因此需要交給 OS 處理。

有些 Page Fault 確實代表非法存取。
但有些反而是** Virtual Memory **正常運作的一部分。

例如程式第一次存取某個尚未實際載入記憶體的 Page 時，就可能觸發 Page Fault，讓 OS 把需要的資料準備好，再讓程式繼續執行。
所以：

Exception 不一定等於「程式錯誤」。
它是：「CPU 在執行目前指令時，遇到了一個需要特殊處理的事件」。

Virtual Memory 的部分我們後面會再仔細說。

5. 那 Trap 又是什麼？

Exception
│
├── 非預期事件 ：例如 Divide by Zero、Page Fault
│
│
└── 程式刻意觸發 例如 System Call → 有些教材稱為 Trap
所以我們上一篇談的 System Call，在某些教材中就會看到「透過 Trap 進入 Kernel」這種描述。
程式執行過程中**「刻意觸發」**的一種同步事件，讓 CPU 暫時停止目前的正常執行流程，轉去執行特定的 Handler。

在許多 OS 教材裡，Trap 常用來描述由程式刻意觸發、同步發生的控制轉移，例如 System Call 或 Breakpoint。

假設 User Program 想要讀取檔案。
我們已經知道 User Mode 的程式不能直接進入 Kernel 想去哪裡就去哪裡，因此需要一個受到控制的方式，把執行權交給 Kernel。
User Program
│
│ 想使用 Kernel Service
▼ trap
刻意觸發受控制的事件
│
▼
CPU 進入 Kernel
│
▼
執行對應 Handler
│
▼
完成 System Call
│
▼
回到 User Program

因此，在一些 OS 教材的描述中，程式會透過 Trap 進入 Kernel，讓 Kernel 幫忙完成 System Call。

今天的結論

Day 1 我們知道一般程式通常在 User Mode 執行，不能任意進入 Kernel。
Day 2 知道程式需要 Kernel 提供服務時，可以透過 System Call 進入 Kernel。

今天則再補上另一個：CPU 不一定是因為程式主動要求才進入 Kernel，也可能是因為硬體事件或目前執行的指令產生了需要處理的狀況。

而不管是哪一種情況，CPU 都不能把原本程式的狀態直接丟掉
它還需要知道：「我剛剛執行到哪裡？」

因為事件處理完之後，原本的程式通常還要繼續跑
而這也就是關於 Process 的概念。
明天的主題：
Day 4｜Process 其實不只是「正在執行的程式」